[sacm] Response to Adam's feedback on Vulnerability Assessment Scenario

Jessica Fitzgerald-McKay <jmfmckay@gmail.com> Fri, 06 May 2016 18:25 UTC

Return-Path: <jmfmckay@gmail.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CBE12D0E4 for <sacm@ietfa.amsl.com>; Fri, 6 May 2016 11:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level:
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRAQsWEa7PHb for <sacm@ietfa.amsl.com>; Fri, 6 May 2016 11:25:34 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABA612D0B9 for <sacm@ietf.org>; Fri, 6 May 2016 11:25:33 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id x201so148465233oif.3 for <sacm@ietf.org>; Fri, 06 May 2016 11:25:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=3lLqonyPpDYROpnO2ZNgZzfrkG9OTcqJ7oMsFxfretc=; b=mcNAl740M9NmVmw52JCwig71pMDPj4ga9/oouR5eLSuZQeQrnNEamdxl93ZODTutEa PdmSXXxH4LUVsFW45mdr70tidFu1VzL1R2jp0hIuX2kdHGRRg1mGQvD9ey6AiXkvMeYG GQysqilTTQ48j46v/GdT5kL8SCZYQ0ooKNDx2jHtwFmwi4N2MVddExYLWZ4lKx78rZEl fHroPP1iSRvbYpRhW1fgb8ik0hGUKcFtlEyQ3GQzFk41luXQx+g6jnAcBN18sPWUL3Q7 24ym9n+L0Rv1qwMH25qizzLdvYg4HEEewVCXJrCi/w/SEwKM3KaS97v+BrxBJwVHvuvv JYwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=3lLqonyPpDYROpnO2ZNgZzfrkG9OTcqJ7oMsFxfretc=; b=crQOQFmloYm7Xu1PAkDyg20gjQtj/cUbRW7GL+S5CZiUQyBxkyz1ObG8Xx46qY5oFK aZqXVQsD1fAxDyVUAMV3vy8kqqIPuAsZZvSV7FdSPEJHjzlP/VTVJtc2EXyKjmUhWtCk QbwC1MEarAIok8tsmnUje1R6jbbcl74Wk+sWkt60IYuMnzM+3ToxA76rWK6MKrZjcCN8 eyEZDosCCp1TLY1R+yE/h+ZWqiMIi93X/d4PNkTq43Lr+8vVb8XGyD2ayc7Tz99VI2CK HLBJHPWoI91oUK3GBsfcOgB3gmSZWnlLjQg+R43IdyG1VA7x3OissK/dWFz9CLzIOfW1 8TKw==
X-Gm-Message-State: AOPr4FXPhfnQiLRE7qEHbLBitWeMaIK6RnXFwdqv2lhwgf0DwpC+GD99p8lD1DuXOx9Tpiu/L7e0WQJxavOvVA==
MIME-Version: 1.0
X-Received: by 10.202.90.3 with SMTP id o3mr9401029oib.96.1462559132693; Fri, 06 May 2016 11:25:32 -0700 (PDT)
Received: by 10.182.120.166 with HTTP; Fri, 6 May 2016 11:25:32 -0700 (PDT)
Date: Fri, 06 May 2016 14:25:32 -0400
Message-ID: <CAM+R6NW_KwUSDAErbcoQ1bw10k37r+b3N0fj9OnnxO-uf6cOgA@mail.gmail.com>
From: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>
To: "sacm@ietf.org" <sacm@ietf.org>
Content-Type: multipart/mixed; boundary="001a113d5edc91a4cc0532309542"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sacm/H4OIKC6ZmqyHE17qaIk_FYgfsdI>
Subject: [sacm] Response to Adam's feedback on Vulnerability Assessment Scenario
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2016 18:25:37 -0000

Adam, thank you for taking the time to make such extensive edits. The
document flows a lot better now, and is much easier to read. Danny, Charles
and I collaborated on our review, and made some additional edits to your
work. They are attached to this email.There are some edits we would like to
call out for particular attention by the group:

   - We got ourselves confused by the definition for Vulnerability
   Management Capability. We added some clarifying (to us) text, so the
   definition now reads: "an enterprise IT capability managing endpoint
   vulnerabilities and associated metadata on an ongoing bases *by
   ingesting vulnerability description information and vulnerability detection
   data, and performing a vulnerability assessment*".
   - Throughout the document, we made changes to clarify when we were
   talking about vulnerability detection information and vulnerability
   detection data.
   - We added a definition for Target Collection (referenced in Section 5
   and previously undefined). It reads: "The task of collecting specific
   endpoint information from the target endpoint in order to make a
   determination about that endpoint (vulnerability status, identification,
   etc.)". We're not sure we are happy with it, though. See open issue #3.
   - We added some clarifying words to the beginning of Section 4.
   - In section 4.2, we changed "vulnerability assessment flow" to
   "vulnerability assessment". They seemed equivalent the way they were being
   used in this document, and "vulnerability assessment flow" didn't appear
   anywhere else in the document.
   - We clarified the text in Section 5 regarding vulnerability detection.
   Previously, it read: Vulnerability detection may be done in a number of
   ways, depending upon the specific vulnerability", followed by a bulleted
   list of endpoint information that may be used to detect a vulnerability. It
   now reads:  Vulnerability detection relies on the examination of
   different endpoint information depending on the nature of a specific
   vulnerability. Common endpoint information used to detect a vulnerability
   includes:", followed by the same bulleted list.
   - We reworded the fourth paragraph in Section 5 (beginning, "The breadth
   of information required. . ." for clarity.
   - In Section 5, paragraph 5, we substituted "vulnerability assessment
   capability" for "vulnerability assessment mechanism".

There are still questions remaining after our review. We would like to get
the work groups feedback on the edits list above, as well as on the
following open issues:

1) We need to determine which items in Section 2 ("Terminology") should be
pulled from the Vulnerability Assessment Scenario and included in the
SACM-wide Terminology draft. Those terms which are only used in the
Vulnerability Assessment Scenario should be defined in this document;
however, any of these terms that will be reused in other SACM documents
should be defined in the Terminology draft.

2) In Section 2 ("Terminology"), vulnerability detection data is defined as
"a representation of vulnerability description information describing
specific mechanisms of vulnerability detection". We interpret this to mean
that vulnerability detection data is a representation of vulnerability
description information that can be used by network tools that participate
in the vulnerability assessment process. Does the group agree that is the
case? If so, is vulnerability detection data a type of guidance, as
described in the SACM Information Model?

3) Regarding the definition of Targeted Collection:
     a) Does targeted collection refer to a server explicitly requesting
additional information from the endpoint to supplement automated
collection? Should the definition be more precise?
     b) Is "targeted collection" even the right term to use in Section 5?
It makes other forms of collection sound un-targeted. Would "supplemental
collection" be a better term?

4) In Section 3, the first bullet states that vulnerability description
[information]  is processed "into a format that the enterprise's security
software tools can understand and use". Is that the equivalent of saying
that the vulnerability description information can be processed into
vulnerability detection data? And is this also equivalent to what we are
trying to say in the third bullet, when we say "The enterprise has a means
of extracting relevant information about enterprise endpoints in a form
that is compatible with the
​ ​
vulnerability description information"?

5) Section 5, paragraph 5 states: "the information beyond that which is
available in the endpoint management
​ ​
capability can be pushed to the vulnerability assessment capability by the
endpoint whenever that information changes". However, we feel this must
necessarily be an information pull, not a push, since the endpoint cannot
know what information is needed until the server requests it. Does the
group agree?

6) Appendix B, paragraph 2 states: "Moreover, the scenario incorporates
long-term storage of collected data, vulnerability description information,
and
​ ​
assessment results in order to facilitate meaningful and ongoing reassessment."
At the SACM side-meeting, there was tentative agreement that SACM was
concerned with data-in-motion, not data-at-rest. Is clarifying language
needed here to address that concern?

​7) Appendix D.2 seems more appropriate for the information model, rather
than this document. Does the group agree?​

We're looking forward to hearing everyone's feedback.

Jess

On Fri, Apr 8, 2016 at 12:06 PM, adammontville <notifications@github.com>
wrote:

> I should also disclose that while I referenced the data table, I did not
> take the time to update the column headers of that table or to add to it,
> if necessary. Personally, I like the idea of referencing the data table,
> but I understand that others may view the world differently.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly or view it on GitHub
> <https://github.com/sacmwg/vulnerability-scenario/issues/4#issuecomment-207495214>
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>
>